remove the random binary file

Currently setting up additional keybindings in aerc via extraBinds leaves aerc literally unusable as these overwrite the default keybindings. This pr changes this so that keybindings specified in extraBinds extend / overwrite the default keybindings.

This would be a pretty big breaking change for users of the module that have configured their own keybinds with the expectation of the current behavior.. But, I do agree it makes sense that extra is additional instead of replace.

I agree. To keep the current behaviour for these users the only option I can currently think of is to add an additional setting with an appropriate name for the use case I'm targeting here. Something called e.g. additionalBinds ...

how does aerc resolve the config?

aerc checks whether this config is present and if it can't find it it copies it into $XDG_CONFIG_HOME/aerc.

Edit: For users depending on the current behaviour any keybindings that were previously specified via this setting should still hold, since in case of duplicate keybindings the latter prevail, see https://aerc-docs.com/reference/aerc-binds.5/. So the only effect they might see is that there are some new keybindings that they hadn't configured before (... and that they are thus not using?) ...

Edit: For users depending on the current behaviour any keybindings that were previously specified via this setting should still hold, since in case of duplicate keybindings the latter prevail, see https://aerc-docs.com/reference/aerc-binds.5/. So the only effect they might see is that there are some new keybindings that they hadn't configured before (... and that they are thus not using?) ...

@khaneliman What do you think? Might not be a breaking change at all.

aerc checks whether this config is present and if it can't find it it copies it into $XDG_CONFIG_HOME/aerc.

Ugh... I hate that kind of config handling.

I'm definitely not a fan of just copy pasting the current defaults in and having to maintain that here... I'm always thinking about what the solution will look like months down the line when someone complains that upstream defaults aren't being respected.

Looking at the docs upstream, it seems like there isn't much flexibility in their config system.

aerc checks whether this config is present and if it can't find it it copies it into $XDG_CONFIG_HOME/aerc.

Ugh... I hate that kind of config handling.

I'm definitely not a fan of just copy pasting the current defaults in and having to maintain that here... I'm always thinking about what the solution will look like months down the line when someone complains that upstream defaults aren't being respected.

Looking at the docs upstream, it seems like there isn't much flexibility in their config system.

I understand and I'm happy to go back to just using readFile, but I tend to avoid IFD as much as I can these days.

I'm definitely not a fan of just copy pasting the current defaults in and having to maintain that here... I'm always thinking about what the solution will look like months down the line when someone complains that upstream defaults aren't being respected.

agreed. From the manpage it's not obvious one has to redefine all mappings ? Cant we define just a few https://man.archlinux.org/man/aerc-binds.5.en and aerc merge them ?

agreed. From the manpage it's not obvious one has to redefine all mappings ? Cant we define just a few https://man.archlinux.org/man/aerc-binds.5.en and aerc merge them ?

Not sure I follow ... . So currently if a user wants to add new/additional keybindings via extraBinds these will be the only ones used by aerc as the module will just create a new binds.conf that holds the new/additional keybindings and only these. My suggestion here is to merge new/additional keybindings with the default keybindings provided by upstream.

Non-nix users would just add their new/additional keybindings to the default binds.conf that will be present in XDG-CONFIG-HOME/aerc.

sry I dont know aerc and I might have missed some previous explanation but typically programs have a set of builtins and binds.conf would be merged. Seems like aerc just starts with 0 bindings if binds.conf exists, forcing you to re-create every binding. Is this correct ?

sry I dont know aerc and I might have missed some previous explanation but typically programs have a set of builtins and binds.conf would be merged. Seems like aerc just starts with 0 bindings if binds.conf exists, forcing you to re-create every binding. Is this correct ?

No worries. No, aerc reads all bindings from binds.conf. If it is not present at startup it is copied into $XDG_CONFIG_HOME/aerc at startup:

The binds.conf file is used for configuring keybindings used in the aerc interactive client.
It is expected to be in your XDG config home plus aerc, which defaults to ~/.config/aerc/binds.conf.
If the file does not exist, the built-in default will be installed. An alternate file can be specified
via the —binds-conf command line argument, see aerc(1).

see https://aerc-docs.com/reference/aerc-binds.5/